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ABSTRACT 

M&S  is  used  in  the  German  Armed  Forces  for  supporting  processes  in  the  following  application  areas: 

•  analysis  and  planning, 

•  procurement, 

•  missions,  and 

•  training  and  exercises. 

These  four  areas  of  application  are  closely  connected  to  each  other,  especially  in  the  context  of 

•  supporting  the  method  of  Concept  Development  and  Experimentation  ( CD&E), 

•  support  of  networking  and  linking  national  and  international  simulations  and  information  systems, 

•  the  entailing  support  for  the  realization  of  Network  Centric  Warfare  (NCW). 

Therefore,  the  further  development  of  M&S  towards  interconnected  systems  by  applying  a  Distributed 
and  Integrated  Test  Bed1  is  indispensable  to  achieve  the  required  capabilities  and  objectives. 

Such  a  test  bed  can  be  used  as  an  armament  test  bed  for  a  fast  and  effective  evaluation  of  technical  and 
technological  solutions  in  a  realistic  and  operational  test  environment  to  support  all  phases  of  the 
development  and  procurement  cycle  of  material  and  equipment  as  well  as  the  other  application  areas  of 
M&S. 

1  in  German:  Verteilte  Integrierte  Erprobungslandschaft,  abbreviation:  VIntEL 
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And  such  a  test  bed  has  to  satisfy  the  demands  concerning  the  acceptance  of  interconnected  simulations  as 
well  as  to  meet  the  requirements  resulting  from  the  NCW  idea  of  joint  and  combined  missions  by  adapting 
to  national  and  international  standards. 

In  this  paper,  we  summarize  the  results  of  a  large  combined  study  of  the  German  government,  industry  and 
research  institutes  that  addresses  the  architectural  aspects  for  such  a  distributed  integrated  test  bed  and 
encompasses  issues  like  ensuring  fair  fight  conditions  as  well  as  the  reproducibility  and  reliability  of 
simulation  results. 


1.0  INTRODUCTION 

The  provisions  for  modeling  and  simulation  (M&S)  in  the  German  Bundeswehr  are  outlined  in  the 
Bundeswehr  Concept  (KdB)  and  are  described  in  more  detail  in  the  Bundeswehr  Modeling  and  Simulation 
Subconcept  (TK  M&SBw). 

According  to  TK  M&SBw,  M&S  is  responsible  in  the  Bundeswehr  for  supporting  processes  in  these  areas 
of  application: 

•  analysis  and  planning, 

•  procurement, 

•  missions,  and 

•  training  and  exercises. 

As  a  part  of  the  armament  organization,  the  Federal  Office  of  Defense  Technology  and  Procurement 
(BWB)  and  its  subordinate  agencies  have  the  task  to  guarantee  that  the  Bundeswehr  demand  is  met  by 
supplying  state-of-the-art  technology  and  modern  equipment  at  economic  conditions.  Therefore,  the  main 
task  of  the  BWB  concerning  the  TK  M&SBw  consists  of  equipping  the  Bundeswehr  with  simulation 
systems  in  all  the  above  mentioned  areas  of  application  and  of  supporting  the  process  of  determination  and 
satisfaction  of  demand  according  to  CPM2  by  means  of  special  models  and  simulation  systems. 

The  four  areas  of  application  are  closely  connected  to  each  other  in  content,  especially  in  the  context  of 

•  supporting  the  method  of  Concept  Development  and  Experimentation  ( CD&E), 

•  support  of  networking  and  linking  national  and  international  simulation  and  information  systems, 

•  the  entailing  support  for  the  realization  of  the  Network  Centric  Warfare  ( NCW  -  NetOpFii). 

The  report  by  the  Directorate  General  of  Armaments  on  realizing  the  transformation  process  concretizes 
the  framework  conditions  established  in  the  TK  M&SBw  by  demanding  the  creation  of  a  common  defense 
modeling  and  simulation  test  bed.  Such  a  test  bed  can  be  used  as  an  armament  test  bed  for  a  fast  and 
effective  evaluation  of  technical  and  technological  solutions  in  a  realistic  and  operational  test  environment 
to  support  all  phases  of  the  development  and  procurement  cycle  of  material  and  equipment.  Therefore,  the 
main  activities  in  the  field  of  R&D  for  common  modeling  and  simulation  were  pooled  in  the  System 
Demonstrator  VIntEL  (SD  VIntEL)  in  early  2008. 

When  approaching  the  SD  VIntEL,  BWB  tried  to  link  as  many  activities  in  the  field  of  modeling  and 
simulation  as  possible  (see  figure  1).  Therefore,  it  does  not  only  consist  of  a  project  with  the  central 
aspects  process  model  and  establishment  of  a  stable,  technical  architecture,  but  also  of  a  project  called 


2 

CPM:  Costumer  Product  Management  (the  procurement  process  of  the  BWB) 
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Agent  Based  Sensor  Shooter  Modeling  (German  short  form:  ABSEM)  as  a  data  farmable  technical  model, 
and  the  project  Knowledge  Management  which  shall  assist  developers  and  users  to  perform  experiments. 
This  paper  deals  mainly  with  the  basic  architecture  of  the  SD  VIntEL. 

Such  a  test  bed  has  to  satisfy  the  demands  concerning  the  acceptance  of  interconnected  simulations  as  well 
as  to  meet  the  requirements  resulting  from  the  NCW  idea  of  joint  and  combined  missions  by  adapting  it  to 
national  and  international  standards. 

Due  to  the  fact  that  such  a  test  bed  requires  a  high  flexibility  and  that  there  is  an  increasing  demand  for 
analysis,  the  implementation  of  new  technologies  is  absolutely  necessary.  Such  new  technologies  may  be 
data  farming  to  analyze  probabilities  and  the  so-called  outliers  in  simulation  runs,  or  an  agent  based 
simulation  to  represent  simulation  participants  with  a  certain  degree  of  artificial  intelligence. 


Figure  1:SD  VIntEL 


knowledge  management 

t 

data  bases 

t 

version  control 


In  this  paper,  we  concentrate  on  the  left  pillar  in  figure  1:  establishing  an  architecture  for  future  projects 
where  national  and  international  simulation  systems  are  linked  together.  The  experience  of  the  past  shows 
quite  clearly  that  the  proper  coupling  of  simulation  systems  beyond  the  technical  level  is  not  an  easy  task: 
reproducibility  and  reliability  of  the  simulation  results  are  still  a  severe  challenge.  Part  of  the  problem  is 
due  to  so-called  unfair-fight  effects,  e.g.  the  different  treatment  of  communication  effects  or  weapon 
effects  in  different  simulation  systems.  One  solution  can  be  the  use  of  uniform  procedures  for  these  effects 
by  all  simulation  systems.  These  procedures  could  be  provided  by  specific  services  to  all  relevant  systems. 
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2.0  REFERENCE  ARCHITECTURE  FOR  THE  TEST  BED 
2.1  General  Requirements 

The  architecture  for  the  test  bed  shall  support  any  experiments  coming  from  the  above  mentioned  M&S 
areas  of  application.  The  following  general  requirements  have  been  defined: 

•  reliability  of  the  simulation  results 

•  reusability  of  simulation  systems,  models  and  documentation 

A  reference  architecture  for  a  SD  VIntEL  test  bed  has  to  be  deduced  from  these  general  requirements.  This 
reference  architecture  describes  only  abstract  component  classes,  service  models,  their  interfaces  and  their 
relations,  without  any  reference  to  a  special  experiment.  Therefore,  in  the  reference  architecture,  no 
specific  simulation  systems  or  services  will  be  named,  because  simulation  systems  and  services  can  vary 
from  experiment  to  experiment. 

For  any  specific  experiment,  an  implementation  architecture  has  to  be  deduced  from  the  reference 
architecture.  In  this  step,  specific  simulation  systems,  services  and  communication  busses  are  selected,  that 
are  suited  for  the  given  task,  and  will  be  connected  to  each  other,  following  the  prescriptions  of  the 
reference  architecture.  Thereby,  the  abstract  component  classes  of  the  reference  architecture  will  be 
replaced  by  specific  instances  within  the  implementation  architecture3.  Component  classes,  which  are  not 
needed  for  a  specific  experiment,  will  be  dropped  completely. 

Other  general  requirements  for  the  reference  architecture  are: 

1 .  performance 

2.  scalability 

3.  Components  that  are  implemented  in  the  programming  languages  C#,  C++  or  Java,  can  be  joined 
to  the  architecture. 

4.  Components  can  be  distributed  spatially  (using  LAN  and  WAN  connections). 

5.  There  exists  an  error  management: 

a.  errors  will  be  categorized 

b.  errors  will  be  logged 

6.  Operations  can  be  conducted  asynchronously. 

7.  Components  shall  have  an  interface  for  initialization  data. 


2.2  Special  Requirements 

The  reference  architecture  shall  foster  a  higher  degree  of  reliability  of  simulation  results  by  the  use  of 
dedicated  special  services.  These  services  shall  support  fair-fight  conditions  between  simulation  systems. 
Therefore,  parts  of  the  internal  logic  of  the  simulation  systems  must  be  transferred  to  the  commonly  used 
services.  In  a  first  step,  the  following  services  will  be  implemented  and  tested: 

1 .  Geo-referenced  Environment,  Object  and  Infrastructure  Service  ( GOIS ) 

This  service  is  responsible  for  the  uniform  delivery  of  environmental  data  of  any  kind. 


3 

For  the  current  VIntEL  experimentation,  some  services  are  already  realized,  e.g.  a  weapon  effects  service.  These  services  will 
be  reused  and  further  developed  in  future  test  bed  applications. 
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2.  Communication  Effects  Service  ( CES) 

This  service  is  responsible  for  the  uniform  evaluation  of  communication  effects.  A  client  has  to 
ask  the  CES,  whether  a  radio  connection  exists  between  a  given  transmitter  and  receiver.  Only  if  a 
connection  exists,  the  receiver  is  allowed  to  interpret  a  radio  signal. 

3.  Weapons  Effects  Service  (WES) 

This  service  is  responsible  for  the  uniform  evaluation  of  effects  of  ammunition  against  targets.  A 
target  may  be  a  platform  or  an  element  of  the  infrastructure,  e.g.  a  building.  Due  to  restricted 
availability  of  vulnerability  data,  only  special  combinations  of  firing  weapon,  ammunition  used 
and  target  material  can  be  considered  by  the  high  fidelity  vulnerability  model  of  the  WES.  Low 
fidelity  models  may  be  used,  if  detailed  information  is  missing. 

A  service  may  not  only  be  used  by  simulation  systems,  but  may  be  called  by  other  services  as  well  (e.g. 
the  GOIS  might  be  called  by  WES  or  CES). 


2.3  Proposed  Architecture 

In  figure  2,  the  current  proposal  for  the  reference  architecture  is  shown.  The  main  elements  of  this 
architecture  are  simulation  systems,  services,  interfaces  to  real  systems,  and  busses.  All  components  can 
be  realized  as  independent  processes,  and  can  be  freely  distributed  over  LAN  or  WAN. 


Data 

Container 


services 


real  systems 


model 
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Services 


model 


model 

C2Sim 
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Figure  2:  Proposed  Reference  Architecture 
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2.3.1  Simulation  Systems 

A  simulation  system  maps  a  piece  of  reality  onto  a  model.  The  details  of  the  model  depend  heavily  on  the 
purpose  and  on  the  application  area  of  the  simulation  system.  Different  simulation  systems  will  therefore 
model  the  same  part  of  reality  differently.  Consequently,  this  will  usually  lead  to  interoperability  problems 
between  the  involved  simulation  systems,  at  least  on  the  higher  levels  of  interoperability  (pragmatic, 
dynamic  and  conceptual).  But  experience  shows  that  in  general  modifications  or  additions  to  the  software 
of  the  simulation  systems  are  necessary  to  accomplish  the  necessary  interoperability. 

2.3.2  Services 

Here,  a  service  is  defined  as  a  component  that  delivers  a  well-defined  functionality  to  applications  or  other 
services,  using  a  standard  interface.  The  main  purpose  of  services  is  to  provide  uniform  solutions  to  all 
involved  systems,  e.g.  a  uniform  treatment  of  weapon  effects,  and  to  reduce  thereby  unfair-fight  effects  as 
much  as  possible. 

To  get  a  clear  understanding  of  the  role  of  services  in  contrast  to  simulation  systems,  we  categorize 
services  under  application  aspects  as  well  as  under  technical  aspects: 

2. 3.2.1  Application-dependent  categorization  of  services 

We  distinguish  services  according  to  the  role  they  are  fulfilling  in  the  architecture.  Up  to  now,  we  have 
identified  the  following  three  categories: 

1.  Infrastructure  services: 

These  services  do  not  influence  the  outcome  of  simulations.  Examples  are  services  for 
initialization  purposes,  for  format  conversion,  or  monitoring. 

2.  Functional  services: 

These  services  represent  a  specific  piece  of  reality,  and  therefore  do  influence  the  outcome  of 
simulations.  Examples  are  services  for  the  evaluation  of  weapon  effects,  or  communication 
effects. 

3.  Adapter  services: 

These  services  link  e.g.  real  systems  to  the  simulation  federation. 

A  clear  separation  between  services  and  simulation  systems  is  hardly  possible,  mainly,  because  some 
services  are  kind  of  simulations.  This  applies  especially  to  the  functional  services. 

2. 3. 2. 2  Technical  categorization  of  services 

Another  way  to  categorize  services  is  according  to  the  way  how  they  are  integrated  into  the  test  bed. 
Again,  we  find  three  categories: 

1.  Federate: 

These  services  are  connected  directly  to  the  simulation  bus.  This  approach  is  most  advantageous  if 
the  functionality  of  the  service  depends  heavily  on  the  object  states  or  on  interactions  in  the 
federation.  It  might  be  that  the  data  exchange  model4  of  the  federation  has  to  be  enlarged  in  order 
to  use  these  services5.  An  example  is  a  weapon  effect  service,  which  transmits  a  weapon  effect  via 
an  interaction  to  the  effected  simulation  objects. 


4  A  FOM  in  the  case  of  HLA. 

5  In  the  current  VIntEL  experimentation,  we  use  a  VIntEL  FOM ,  which  is  an  extension  of  the  RPR  FOM  2.0  D17. 
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Simulation  systems  can  use  the  established  interface  to  the  simulation  bus  in  order  to  use  these 
services.  But  it  might  be  that  they  have  to  be  adapted  to  an  extended  data  exchange  model. 

2.  Web-service: 

These  services  do  not  use  the  simulation  bus  but  a  dedicated  service  bus  or  data  bus.  This 
approach  might  be  useful  if  legacy  simulation  systems  shall  use  a  service,  but  there  is  no  way  to 
modify  their  simulation  interface  (e.g.  a  training  simulation  using  DIS).  Adaptations  to  these 
systems  can  then  be  limited  to  the  interface  to  the  service  bus. 

3.  Use  of  service-proxy: 

It  is  possible  to  implement  a  service  not  as  a  simulation  (with  a  direct  connection  to  the  simulation 
bus),  but  to  use  a  service-proxy  for  the  connection  between  simulation  bus  and  service.  The 
advantage  of  this  approach  is  that  the  simulations  can  still  use  their  well-established  interface  to 
the  simulation  bus.  An  example  is  the  connection  of  a  real  system  without  a  simulation  interface 
like  HLA  or  DIS  to  a  simulation  bus. 

In  any  case,  a  Service  Canonical  Object  Model  (S-COM)  has  to  be  defined  for  each  service.  The  S-COM  is 
the  data  exchange  model  of  the  service  and  should  be  kept  independently  from  the  specific  implementation 
of  the  service. 

According  to  this  definition  of  S-COM,  the  S-COM  must  be  mapped  onto  the  used  exchange  model.  If  the 
service  is  realized  as  a  federate,  the  S-COM  will  be  mapped  onto  a  Sendee  Simulation  Object  Model  (S- 
SOM),  if  the  service  is  realized  as  a  web-service,  the  S-COM  will  be  mapped  onto  a  WSDL-specification. 
Regardless  of  the  technical  category  the  service  belongs  to,  the  same  semantics  should  be  modeled  in  the 
same  way,  e.g.  the  semantic  expressions  describing  geometrical  abstractions  like  points  should  be  modeled 
in  the  same  way,  regardless  whether  an  HLA-SOM  or  a  WSDL-interface  is  used. 

2.2.3  Busses 

Several  busses  are  used  for  connecting  the  components  of  the  reference  architecture: 

•  a  simulation  bus  for  connecting  the  simulation  systems, 

•  a  service  bus  for  connecting  service  providers  and  clients, 

•  a  data  bus  for  the  transmittal  of  geo-referenced  images  or  other  voluminous  data, 

•  one  or  more  tactical  busses  for  the  coupling  with  C2-systems,  e.g.  via  MIP  or  Link. 

If  needed,  more  busses  would  be  possible  (e.g.  voice  communication  for  controlling  experiments). 

As  far  as  possible,  international  standards  are  used  for  all  busses. 


2.4  Process  Model 

To  make  sure  that  the  reference  architecture  for  test  beds  is  applied  properly  in  specific  applications,  the 
process  model  VEVA6  was  set  up.  VEVA  borrows  heavily  from  the  FEDEP  (and  its  proposed  successor, 
DSEEP)  and  from  similar  activities  in  other  working  groups,  e.g.  MSG-052. 


6  VEVA  =  Vorgehensmodell  fiir  den  Einsatz  der  VIntEL-Architektur  =  Process  Model  for  the  Application  of  the  VlntEL 
Architecture 
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3.0  VERIFICATION  OF  THE  ARCHITECTURE 

To  prove  the  applicability  of  the  proposed  reference  architecture,  a  series  of  experiments  was  conducted. 
In  these  experiments,  the  following  components  were  used  (see  figure  3  and  4  for  examples): 


1.  simulation  systems: 

a.  constructive  simulations  ABSEM  (EADS)  and  PABST  (IABG) 

b.  virtual  vehicle  simulations  GeneSys  and  GenPlatSim  (both  IABG) 

c.  virtual  target  simulation  dome  at  WTD  8 1  in  Greding 

2.  services: 

a.  geo-referenced  environment  service  GOIS  (IABG) 

b.  communication  effects  service  KESS  (Thales) 

c.  weapons  effects  service  WES  (IABG) 

d.  GEPARD- proxy  (gateway  between  anti-air  tank  GEPARD  an  HLA) 

e.  Recce-proxy  (gateway  between  reconnaissance  systems  and  HLA) 

f.  C2SimProxy  (gateway  between  MIP  DEM  and  HLA) 


3.  busses: 

a.  simulation  bus:  HLA  with  MAK  RTI  v3.x  or  PITCH  pRTI  v3.x  and  VIntEL  FOM 

b.  service  bus:  HTTP  /  SOAP 

c.  data  bus:  XML  over  TCP/IP  for  synthetic  environment  data  and  STANAG  4609  for  video 
data 

d.  tactical  bus:  MIP  DEM 

4.  real  systems: 

a.  anti-air  tank:  GEPARD  (German  anti-air  tank) 

b.  reconnaissance  system:  AMFIS  (evaluation  of  UAV  data) 

c.  C2-system:  FIS-H  (C2-system  of  the  German  Army) 


Three  experiments  were  devoted  to  the  use  of  services  to  reduce  unfair-fight  effects  (use  of  a  weapon 
effects  service,  a  communication  effects  service,  or  a  geo-referenced  data  service).  In  a  further  experiment, 
several  real  systems  were  linked  with  simulation  systems  and  services. 

The  main  findings  of  these  experiments  are  described  in  the  following  sections. 


19-8 


RTO-MP-MSG-069 


NATO 

OTAN 


Architecture  for  a  Distributed  Integrated  Test  Bed 


Figure  3:  Screenshots  of  the  services  GOIS  (top  left),  KESS  (top  right)  and  WES  (bottom) 


Figure  4:  Real  system  AAT  GEPARD  (left)  and  virtual  target  simulation  dome  in  Greding  (right) 
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3.1  Use  of  Weapon  Effects  Service  (WES) 

The  Weapon  Effects  Service  (WES)  is  used  to  deliver  uniform  weapon  effects  to  all  involved  systems, 
concerning  effects  against  platforms  and  infrastructure,  e.g.  buildings.  For  this  experiment,  the 
constructive  simulations  ABSEM  and  PABST  and  the  virtual  simulations  GeneSys  and  GenPlatSim  were 
used.  The  following  results  were  obtained: 

1.  It  could  be  established  that  the  WES,  triggered  by  an  interaction  MunitionDetonation,  evaluates 
the  damage  effects  of  platforms  and  communicates  the  results  into  the  federation  via  a  new 
interaction  WeaponEffect. 

2.  The  simulation  systems  could  deactivate  their  internal  evaluation  of  damage  effects,  and  deduce 
the  damage  effects  of  their  own  entities  from  the  interaction  WeaponEffect. 

3.  It  turned  out  that  the  granularity  of  damage  effects  in  the  interaction  WeaponEffect  is  very  coarse. 
In  the  future,  a  more  detailed  description  of  damage  effects  will  be  introduced. 

3.2  Use  of  Communication  Effects  Service  (CES) 

The  Communication  Effects  Service  (CES)  is  used  to  deliver  uniform  communication  effects  to  all 
involved  systems.  For  this  experiment,  the  constructive  simulations  ABSEM  and  PABST  and  the  virtual 
simulation  GenPlatSim  were  used.  The  following  results  were  obtained: 

1 .  It  could  be  established  that  the  CES  determines  the  probability  of  a  radio  connection,  depending 
on  the  exact  positions  of  sender  and  receiver. 

2.  Fair-fight  conditions  could  be  improved  by  applying  the  CES  to  the  communication  between  both, 
blue  and  red  platforms,  modeled  by  different  simulation  systems. 

3.  Fair-fight  has  to  be  improved  in  the  future  by  applying  the  CES  also  to  the  communication  that  is 
modeled  internally  in  a  simulation  system. 

3.3  Use  of  Geo-referenced  Environment,  Object  and  Infrastructure  Service  (GOIS) 

The  Geo-referenced  Environment,  Object  and  Infrastructure  Service  (GOIS)  is  used  to  deliver  uniform 
information  about  the  environment  to  all  involved  systems.  The  GOIS  serves  two  use  cases:  initialization 
and  dynamic  change.  In  the  use  case  initialization,  an  application  can  query  the  initial  state  of  all  buildings 
in  an  area  of  interest,  before  starting  a  simulation  run  (pull).  In  the  use  case  dynamic  change,  the  GOIS 
will  inform  applications  about  changes  of  buildings  that  occur  during  the  simulation  (push). 

For  this  experiment,  the  virtual  simulations  GeneSys  and  GenPlatSim  were  used.  The  following  results 
were  obtained: 

1.  GOIS  is  able  to  manage  buildings  and  their  damage  state,  and  can  provide  the  relevant 
information  to  a  client  either  after  a  pull  or  by  a  push. 

2.  The  damage  of  buildings  after  a  MunitionDetonation  was  determined  in  close  collaboration  with 
the  WES:  environmental  data  were  sent  from  the  GOIS  to  WES,  modified  by  the  WES,  and  sent 
back  to  GOIS.  In  this  way,  damages  of  buildings  can  be  cumulated. 
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3.4  Coupling  of  simulation  systems  with  real  systems 

In  this  experiment,  several  real  systems  were  put  into  a  synthetic  environment: 

1 .  a  real  anti-air  tank  GEPARD ,  joined  into  the  HLA-federation  via  a  special  proxy  service, 

2.  the  reconnaissance  system  AMFIS  for  the  evaluation  of  UAV  data,  joined  to  HLA  via  a  Recce- 
proxy. 

3.  the  C2-system  FIS-H,  joined  into  the  HLA-federation  via  a  C2SimProxy. 

The  synthetic  environment  was  simulated  by  the  constructive  simulation  ABSEM,  the  virtual  platform 
simulation  GeneSys  and  the  target  simulation  dome.  The  connection  between  the  real  systems  and  the 
synthetic  environment  is  established  by  several  gateways:  the  GEPARD- proxy,  the  Recce-proxy,  and  the 
C2SimProxy  (see  figure  5). 


j r-TT  i  - 

_  _  •  * 

ABSEM  GeneSys  Dome 

simulation  systems 


Figure  5:  Implementation  of  the  architecture  (here:  coupling  of  simulation  systems  with  real 

systems) 

The  systems  were  distributed  over  five  locations  in  Germany  and  connected  via  a  WAN. 

An  important  observation  during  this  experiment  was  that  long  latency  times  in  the  WAN  corrupted  the 
experimental  results,  e.g.  position  and  detonation  information  were  delayed  in  such  a  way  that  fair-fight 
conditions  could  not  be  guaranteed  anymore  by  the  WES.  Possible  solutions  have  to  be  examined  in  the 
future:  stringent  evaluation  of  time  tags,  or  strict  use  of  time  management. 
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The  process  model  VEVA  was  tested  the  first  time  in  this  experiment.  The  results  showed  that  VEVA  is 
very  useful  for  organizing  the  experimental  activities.  Two  conclusions  from  this  first  experience  with 
VEVA  are  that  more  steps  are  needed  at  some  points  of  the  workflow,  and  that  more  details  should  be 
defined,  concerning  the  documentation  and  other  artifacts,  which  have  to  be  produced  during  the  single 
steps. 


3.5  Summary  of  the  experiments 

In  summary,  the  following  results  were  obtained: 

1 .  All  experiments  were  based  on  the  proposed  reference  architecture. 

2.  The  models  of  WES,  GOIS  and  CES  can  be  used  as  starting  points  for  the  development  of  corre¬ 
sponding  S-COMs.  In  addition,  an  S-SOM  can  be  defined  for  WES,  and  a  WSDL  for  CES. 

3.  For  each  experiment,  an  implementation  architecture,  and  a  Federation  Agreements  Document 
were  established.  For  all  experiments,  the  VIntEL  FOM  was  used  (cp.  footnote  5).  The  services 
KESS  und  WES  and  the  simulation  systems  GeneSys,  GenPlatSim  and  PABST  were  adapted  to 
these  specifications. 

4.  All  functional  services  and  time  management  were  used  successfully. 


4.0  CONCLUSIONS 

A  reference  architecture  for  the  distributed  integrated  test  bed  SD  VIntEL  was  established.  Special 
emphasis  is  set  on  the  use  of  services  which  provide  uniform  functionality  to  other  components  and  shall 
be  used  by  all  simulation  systems  instead  of  their  own  internal  logic  to  reduce  the  effects  of  unfair-fight. 
Different  bus  systems  were  introduced  to  logically  and  physically  separate  the  predominant 
communication  standards  for  C2  systems,  distributed  simulations,  services,  real  systems,  and  other 
applications.  Proxies  were  used  to  establish  information  exchange  between  different  busses.  This  reference 
architecture  was  able  to  support  all  verification  experiments. 

Several  experiments  were  conducted.  For  each  experiment  a  specific  implementation  architecture  was 
derived  from  the  reference  architecture.  Several  constructive  and  virtual  simulation  systems  were  adapted 
to  the  use  of  services,  thus  reducing  unfair  fight,  e.g.  in  the  cases  of  weapon  effects  and  communication 
effects.  The  services  could  be  reused  across  the  various  experiments. 

As  expected,  it  turned  out  that  the  use  of  services  for  the  reduction  of  unfair-fight  effects  is  not  for  free  - 
the  adaptation  of  simulation  systems  has  to  be  taken  into  account.  But  it  was  established  that  is  it  very 
useful  for  the  implementation  of  specific  experiments  to  re-use  not  only  simulation  systems  and  services, 
but  the  architecture  as  well. 
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5.0  FUTURE  ACTIVITIES 

The  final  presentation  of  the  VIntEL  program  is  scheduled  for  2013.  Right  now,  the  reference  architecture 
is  evaluated  further  by  preparing  and  conducting  more  extensive  experiments.  The  process  model  VEVA 
will  be  elaborated.  One  of  the  most  important  aspects  of  future  activities  will  be  a  more  detailed 
exploration  of  fair-fight  problems. 

Considering  the  conditions  and  provisions  described,  the  future  Bundeswehr  M&S  landscape  might 
present  itself  as  follows: 

The  simulation  of  tasks  taken  from  the  four  areas  of  application  is  realized  in  test  beds,  in  which  the 
necessary  basics,  e.g.  object  and  environmental  data  but  also  missions  and  framework  conditions  are 
deposited  in  data  containers  subject  to  revision  control.  They  are  complemented  by  an  initialization  service 
which  deposits  the  start-up  parameters  of  the  simulators  involved.  These  measures  are  essential  for 
reproducibility  and  reusability. 

All  simulators  involved  in  the  test  bed  are  limited  to  their  core  tasks,  also  in  non-network  operation,  i.e. 
they  simulate  only  what  is  not  represented  through  common  services.  Thus,  a  large  number  of  fair-fight 
problems  can  be  resolved  and  costs  can  be  saved.  Furthermore,  these  test  beds  should  be  subjected  to  a 
W&A  process  (Verification,  Validation,  and  Accreditation)  and  be  accompanied  by  a  model  management 
system. 

All  test  beds  are  based  on  the  Bundeswehr  Simulation  and  Testing  Environment  (SuTBw),  which  provides 
the  technical  foundations.  In  addition  to  the  requirements  for  a  test  bed  interoperability,  SuTBw  also 
defines  the  procurement  standards  for  future  simulations  of  the  Bundeswehr,  which  are  subjected  to  a  pre¬ 
analysis  that  is  supported  by  an  agent-based  simulation  capable  of  data  farming. 
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